III. REMARKS 

A. Claim Amendment 

Applicant has amended Claims 14 and 22. No new matter is presented. After 
entry. Claims 13-17 and 19-30 are pending. Claim 18 was previously canceled. 

B. Overview of the Invention 

The invention is generally directed to a computer-based method for managing the 
processing of forms (e.g., paper forms applying for financial products) in a system 
processing multiple different types of forms, and where the machine-based reading process 
(e.g., OCR or ICR) can produce results that vary in accxaracy. Accordingly, the invention 
provides a method for processing the machine-read forms in order to validate and/or repair 
the form data before further processing. Therefore, generally the processing is referred to 
as "validation & repair processing." 

Particularly, the invention employs a contingent workflow approach that performs 
validation processing of the forms in different ways and order based on the results of the 
machine-based reading (e.g., OCR or ICR) process. In particular, the validation processing 
of the forms is prioritized based on priorities assigned based on a form code identifier 
associated with the forms. If the Examiner properly constmes the claims in accordance 
with the specification, it is clear that the applied reference is thoroughly distinguished. 

C. The Rejections 
Indefiniteness 
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The Examiner objects to the several aspects of the claims as being vague or 
confusing. Applicant respectfully submits that the claims use readily understood language 
and that the person of ordinary skill would understand the boimds of the claimed invention. 
The test is whether the claims would reasonably define the boxmds of the claimed 
invention to the person of ordinary skill. Applicant shall address each of the Examiner's 
concerns one by one. 

1 . The Examiner indicates that the "routing steps are vague and indefinite with 
respect to the algorithm for routing a form to a repair system based on a code identifier." 
Office Action at 2. The Examiner does not identify the claim, but it appears he refers to 
Claim 13. Applicant submits that the claim language is very clear. Claim 13 recites 
"determining the form code identifiers for the forms" and "routing the forms to different 
validation and repair systems based on the determined form code identifiers." That 
language is very straightforward, and the person of ordinary skill would have no difficulty 
understanding what is being claimed. 

The specification clearly sets forth how form code identifiers are determined and 
then the forms are routed to different validation & repair systems accordingly. See Figure 
4 of the Specification. The person of ordinary skill would have no difficulty 
understanding, for example, how a form with form code XXX might be routed to 
validation system A while a form with form code YYY might be routed to validation 
system B. Applicant also refers the Examiner to Figure 1 of the specification, which 
shows how machine-read (e.g., character recognition) forms can be routed to various 
validation & repair systems, such as validation system 120, validation system 122, 
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validation system 124, and validation system 126. Applicant does not see how the claim 

language could be any more clear. 

2. The Examiner also indicates that "the step of processing comprising a workflow 
contingent on the type of error received from external data entry operators" is vague. The 
Examiner states: "At what point does a system [be] come extemal"? Applicant believes 
that the specification clearly teaches how there can be validation & repair processing 
conducted by extemal validation & repair systems, followed by additional review by 
internal validation & repair systems. See Figure 4 of the Specification. Nevertheless, to 
moot the issue, Applicant has removed that language from Claim 22. Claim 22 now reads 
"wherein step (f) of processing comprises a workflow contingent on the type of error in the 
form that has been read into electronic format based on computer-implemented character 
recognition ." This is clearly supported in the specification at page 11, which indicates that 
processing at step 428 (second level validation & repair) can be prioritized according to the 
types of errors in the machine-read forms that were not resolved in steps 420-424 (first 
level validation & repair). 

3. Next, the Examiner asserts that "the step of processing according to a contingent 
workflow comprising processing forms as fiill images when the form code identifier can be 
determined, and processing forms as full images when the form code identifier can not be 
determined is confiising. The code identifiers are said to be part and parcel of the form as 
opposed to information filled in by the user. Is the code unreadable or vmidentifiable[?]." 
See Office Action at 2. 
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Applicant responds that it is well known that machine reading processes (e.g., 

character recognition) are not always 100% accurate and reliable. Just by way of example, 

a form might have an embedded form code identifier XYZ in the upper left hand comer. 

Forms are scanned into images and then they are processed by machine reading processes 

(e.g., character recognition, or CR). The machine reading process will not successfully 

interpret the form code identifier 100% of the time. Some small percentage of the time, the 

CR process will have some difficulty decoding that field. All algorithms have some error 

rate, and machine reading is no different. Additionally, the image that the machine reading 

process operates on might be "noisy," such as in the case where it was received by 

facsimile. 

The invention set forth in dependent Claim 21 (which appears to be what the 
Examiner is referring to) simply provides that when the form code identifier can be 
determined, the forms are validation-processed as parsed snippets. If the form code 
identifier cannot be determined, the form is validation-processed as a full image. This is 
clearly set out in the specification, where Figure 4 describes how if the form code cannot 
be ascertained (see blocks 404, 406, 408, 414), then the fiiU image is processed (block 
418). If the form code can be determined (see blocks 404, 408, 416), then parsed snippets 
are processed. 

Finally, the Examiner is correct that the form code identifiers are provided by the 
form provider, rather than being written in by the applicant. This does not mean that the 
form code identifiers can be properly read with a 0% error rate, as explained above. 
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Obviousness 

The Examiner relies on "Cardiff, Teleform Elite" from www.Cardiff com 
(hereinafter, the "Cardiff reference" or "Cardiff) to reject all claims under § 103. 

First, Applicant notes that the reference is undated. The reference bears a copyright 
of 1991-2000, which clearly means that the reference is from 2000. Applicant's 
application was filed on June 20, 2000, and enjoys priority to a provisional dated February 
15, 2000. Unless the Examiner can establish that the Cardiff document was published 
in 2000 earlier than February IS***, the reference is not prior art. Applicant requests 
that the reference be withdrawn unless the Examiner can prove up the date of this 
reference. 

Second, the Examiner has rejected Claims 13-30 en masse without addressing their 
specific features. As Applicant pointed out in the last response, a number of the dependent 
claims include fiirther patentable features. The Examiner did not address those claims in 
the present office action. Applicant shall again highlight some of those claims for the 
Examiner's consideration. 

Independent Claim 13 

Cardiff discloses a form capture processing system that includes character 
recognition for receiving, scanning, and validating forms that may include form ID codes. 
Cardiff at 2-3. The processed forms are then forwarded or exported to back office 
applications for fiirther processing. Cardiff at 3. In simi, Cardiff is similar to the prior art 
systems described in Applicant's background of the invention, see Specification at 1-2, 
which the present invention improves upon. Cardiff, which is a very high-level and non- 
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technical reference, does not remotely suggest the features of Applicant's invention which 

greatly increase the efficiency of form processing. 

In sum, Cardiff discloses a very robust neural network-based CR process to read 
each form, along with a robust validation & repair process to validate/repair each form. 
Cardiff is not concemed at all with prioritizing validation & repair among different 
forms, nor with routing different forms to different validation & repair systems for 
validation processing. AppUcant's invention solves the problem of how to allocate 
validation & repair resources to deal with potentially thousands of application forms 
coming in daily, and which may involve multiple different types of forms. Applicant's 
invention would allow for the validation processing of the most important forms first, and 
for the validation processing of those forms by validation & repair systems best equipped 
to handle them. Cardiff does not even address these issues. 

Claim 13 provides for ^^assigning priorities to the forms based on the 
determination of the form code identifiers" and "processing the forms for validation 
and repair . . . based ... on [the] priorities assigned." In other words, the invention 
provides that validation & repair processing of forms is prioritized based on the form code 
identifiers. Cardiff does not remotely disclose this feature. Cardiff simply notes on page 2 
that the forms may have form ID codes. Cardiff does not state how form ID codes are 
processed or even whether they are processed. Cardiff is completely silent. Cardiff does 
not remotely suggest that the validation & repair processing of forms would be prioritized 
based on the form ID codes. In fact, Cardiff refers to "Point & Click Validations" on page 
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2 and "Custom Validation" on page 3 with no suggestion whatsoever regarding vaUdation 

priority based on form ID codes. 

Claim 13 also provides that "some of the assigned priorities for some forms are 
different from the assigned priorities for other forms." Again, Cardiff is completely 
silent. Cardiff indicates various ways for validating data for a given form ("Point & Click" 
or "Custom"), but there is no suggestion about prioritizing the validation processing 
between different forms. Cardiff does not teach or even address the concept of prioritizing 
validation processing as between different forms. 

Claim 13 also provides for "routing forms to different validation and repair 
systems based on the determined form code identifiers." This feature allows for 
routing certain types of forms to certain validation and repair systems, e.g., those that are 
most suited for and/or experienced with certain types of forms. Cardiff does not teach or 
suggest anything about routing forms to different validation systems, much less routing 
forms based on form code identifiers. In fact, Cardiff does not even show the existence of 
multiple validation & repair systems in the very first place. 

Rather, Cardiff basically discloses (1) scanning forms ("Total Scanner Support"), 
(2) character recognition ("Superior Recognition with Tri-CR"), (3) validation ("Point & 
Click Data Validation" and "Custom Validations"), and (4) exporting the processed forms 
to back office applications ("Export Connectivity"). There is absolutely noting in Cardiff 
suggesting that form ID codes would be processed in order the route the machine-read 
forms to different validation & repair systems. 
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Turning to the Examiner's comments, he admits that Cardoff s very high-level 
disclosure does not "expressly teach" the features set forth in Applicant's claim 13. See 
Office Action at 3. The Examiner observes that Cardoff refers to address comparison with 
a previously known database and passing documents/data to back office applications. Id, 
Neither of these remotely relate to the claim features noted above. An address comparison 
is part of Cardoff s validation (see "Custom Validations" — "Address comparison with 
your customer database", Cardoff at 3)~it has nothing to do with assigning priorities 
before validation takes place. It has nothing to do with routing to different validation 
systems. It has nothing to do with using form code identifiers as a basis for assigning 
priorities and routing forms. 

The other process the Examiner refers to, passing documents/data to back office 
applications, is what occurs after Cardoff s validation is complete (see "After jobs are 
processed, pre-made export Connect Agents automatically pass documents and data to 
back office applications", Cardoff at 3)~it has nothing to do with assigning priorities 
before validation, nor with routing to different validation systems. It has nothing to do 
with using form code identifiers as a basis for assigning priorities and routing. 

The Examiner's assertion that the forms are "inherently prioritized" when form 
data is compared to a database, see Office Action at 4, is simply off point. When Cardoff 
compares form data to a database, that is part of Cardoff s validation processing ("Custom 
Validations"). The form is already being validated (reviewed and corrected). No priorities 
are being assigned as to which form types to validate and by which validation systems 
because validation on the specific form is already taking place. 
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Dependent Claim 14 

Dependent claim 14 provides that the "forais are subdivided into snippets 
forwarded to validation and repair systems such that at least some validation and repair 
systems perform validation and repair on snippets and not on the entirety of the form." 

This beneficial feature provides that a form can be broken up into its constituent 
fields ("snippets") so that individual validation & repair systems can focus on particular 
snippet types. For example, consider an exemplary form in Figure 5, where a form could 
be broken up into a name snippet 502, address snippet 504, social security snippet 504, and 
a annual salary snippet XXX (not shown). Just by way of example, for efficiency purposes 
it may be desirable to have one validation & repair system only work on name snippets, 
another only work on address snippets, and yet others working on social security numbers 
and salary snippets. To do so will make the validation & repair processing more efficient 
since the validation & repair systems will regularly work on the same type of snippet data. 
To do so may also enhance the security of the system since no one validation & repair 
system would have all of the personal data of an applicant that could be used for ID theft or 
other nefarious purposes. 

The Cardiff reference does not remotely teach or suggest the feature of subdividing 
forms into snippets and routing different snippets to different validation & repair systems. 
Cardiff does not even reference the concept of this sort of "division of labor" to enhance 
efficiency. Cardiff does not even reference the security concem of making all form data 
available to a single person. Therefore, not only does Cardiff not disclose the features of 
amended Claim 14, but it does not provide any motivation for the significant changes that 
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would be required to arrive at the claim. In fact, Cardiff actually teaches away from Claim 

14. 

Dependent Claim 21 

Claim 21 provides that the validation processing is performed using parsed snippets 
when the form code identifier can be determined, and that the validation processing is 
performed using full images when the form code identifier can not be determined. First, 
the Examiner seems to be having difficulty regarding the claim language. The concept is 
clearly described in the specification, where validation & repair systems may operate on 
full image data or parsed snippet image data: 

"The daily volume of forms received 400 for data capture 230 may vary 
substantially. For this and other reasons, it may be advantageous to utilize extemal data 
entry vendors 240 capable of processing either parsed 416 or full image forms 418. Figure 
4 therefore indicates that electronic form data may be transmitted 420 to extemal data entry 
vendors for the purpose of verifying the automated read 402. Extemal data entry 240 may 
involve, for example, an on-screen comparison between a bit mapped image of snippet or 
full image and the textual equivalent produced by character recognition software." See 
Specification at 10. See also Figure 5, which discloses how the full form 501 can be 
broken down into its snippets. 

Claim 21 provides for conducting validation & repair processing using full images 
or using snippet images depending on whether the form code identifier can be determined. 
Cardoff does not remotely teach or suggest this feature. The Examiner asserts that "[i]t 
seems reasonable that this step is inherent in the system described by this reference." 
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There is simply no basis for this assertion. Cardoff does not even discuss snippet 

processing versus full image processing, so the notion that Cardoff could possibly 

inherently provide for selective snippet/full image processing based on whether a form 

identifier could be ascertained is unsupportable. 

Dependent Claim 28 

Claim 28 provides that the validation & repair processing is contingent based on 4 
different parameters, including (1) the ability to determine the form code identifier; (2) the 
assigned priority of a form; (3) an indication of a change of address; and (4) an indicia of 
the type of error resulting from the reading step. 

Applicant specifically addressed this claim in the last response, which the instant 
Office Action does not address. Cardoff does not disclose validation processing contingent 
on any of these parameters, much less all four. Cardoff does not teach validation & repair 
processing that is carried out differently based on the ability to determine a form code ID. 
As noted above, Cardoff says nothing about how the form code ID might be used. Cardoff 
does not say anything about assigning priorities to forms for validation processing. 
Cardoff says nothing about performing validation processing differently based on whether 
there is an indication with the form of a change of address. Finally, Cardoff says nothing 
about performing validation processing differently based on the nature of an error in the 
machine reading (character recognition) process. 
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rV. Conclusion 

Applicant respectfully submits that the application is in condition for allowance and 
respectfully requests a notice of allowance for the pending claims. Should the Examiner 
determine that any further action is necessary to place this application in condition for 
allowance, the Examiner is kindly requested and encouraged to telephone Applicant's 
undersigned representative at the number listed below. 

No fees are believed to be required for this filing. If any additional fees are 
deemed necessary. Applicant hereby provides authorization to charge such fees against 
deposit account 50-0206. If any refunds are due. Applicant hereby provides authorization 
to credit such refunds against the deposit account. 



Respectfully submitted, 



Stephen T. Schrein) 
Reg. No. 43,097 




Date: SSTT. 1. ^5 



Hunton & Williams (Phone: 202-955-1500) 
1900 K Street, N.W. 
Washington, D.C. 20006-1 109 
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